In a robotic painting application, there may be hundreds of different teaching point (TP) programs on multiple robot controllers that handle the painting of a single vehicle. For instance, each TP program may cause a paint applicator disposed on a robot arm to follow a specified path and assume a specified orientation in order to properly apply paint to the vehicle. If there is an area on a vehicle that is not getting painted properly, finding the correct TP program, the correct taught points associated with the TP program, and the correct application instructions to properly paint the area at issue can be very difficult and time consuming, especially for non-expert users of the robotic system performing the painting application. This is very inefficient in a production environment.
Graphical offline programming solutions have been developed to simplify the process of teaching a robotic path for executing a specified robotic application, such as the painting application discussed hereinabove. Such software products generate and display a 3-D space for simulating a robotic process to be carried out therein. The simulation of the robotic process may include generating each TP program associated with the robotic process within the 3-D space in the form of a 3-D path or line to be followed by a robotic component. The generated 3-D path may be visually displayed to a user of the software product or the 3-D path may be hidden from view. If shown visually, each TP program may further be represented in the form of all of the taught points, or nodes, that comprise the 3-D path. Because the 3-D space is presented to a user of the software product on a two-dimensional (2-D) display screen, such software products are often equipped with a user interface (UI) that allows a user to change a position and posture from which the 3-D space is viewed, effectively changing a “camera view” displayed on the 2-D display screen. The camera view displayed on the 2-D display screen is essentially a 2-D projection of the 3-D space in the form of an image.
A single painting application may include the use of multiple robots, and each robot may be responsible for carrying out hundreds of TP programs. Each TP program, in turn, may be comprised of hundreds of taught points (nodes). The high number of TP programs and associated taught points makes displaying graphical representations of each TP program undesirable. The generating of a graphical representation of each TP program and associated taught points is time consuming and cumbersome from a computational standpoint. Furthermore, the high number of TP programs used to program a single robotic application leads to many TP programs and associated taught points being represented as overlapping or closely spaced, making identification of a specified TP program in a display increasingly difficult. For these reasons, many software products do not display the graphical representation of each and every TP program when the user navigates the 3-D space representing the workcell. Instead, these software products require the user to identify which TP programs are to be represented graphically before selecting a specified TP program for editing.
In order to identify and select a specified TP program, the user of the software product may utilize the UI to place a desired region of the 3-D space having the specified TP program represented therein within the view of the 2-D display screen. The user then uses a cursor to select a region of the 3-D space projected to the 2-D display screen where the specified TP program path is located, or believed to be located. For instance, if a door of a vehicle is not being painted properly, the user would navigate the 3-D space to place the vehicle door within the view of the 2-D display screen. The user then “rubber bands” the problem area on the vehicle door as projected and shown on the 2-D display screen. The “rubber banding” of the selected area is usually performed by drawing a rectangular box over the 2-D display screen. Once a region is selected on the 2-D display screen, the software product may then identify and display each taught point associated with each TP program path located within the selected region. The taught points are located in the 3-D space and must be projected to the 2-D display screen. A calculation is done to filter the points and choose those points that are located within the user selected screen area.
As explained hereinabove, the number of taught points comprising the TP programs within the selected region may be in the hundreds or greater. Accordingly, the time needed to identify and display each taught point within the selected region may be excessive due to the sheer number of computations needed. Furthermore, displaying each taught point located within the selected area often creates a “cloud” of overlapping or closely spaced taught points, making identification of a specific TP program or taught point very difficult. The excessive number of computations needed to display the taught points in this manner has caused existing software products to be limited to identifying a single TP program at a time or only those TP programs associated with a selected robot controller. Otherwise, the user would experience unexpected delays, leading to excessive expense, lost time, and potentially frustration of the user.
It would therefore be desirable to provide a method of selecting a TP program within a 3-D space generated by a robot simulator that provides a user interface that allows for selection of a specific area projected to a 2-D display screen, that automatically identifies and selects those TP programs associated with the area selected on the 2-D display screen in a time efficient manner, and that allows for the identification and selection of multiple TP programs assigned to multiple robot controllers associated with the robotic application.